Re: Performance Counters

[Luke Berndt]

...and I think found atleast some of my problems. gr-perf-monitorx will exit 
with the same error message no matter what the exception is. I changed it to 
print out the Exception. It looks like a number of additional libraries are 
required. To use it I needed to install:
apt-get install libgraphviz-dev
apt-get install graphviz
pip3 install pygraphviz

It also looks like the NetworkX library may have been updated because it is 
complaining about some parameters. I will try to sort through this and submit a 
PR.

Performance Counters

[Luke Berndt]

I am trying to enable Performance Counters so I can watch the buffer size of 
various blocks in a C++ GNU Radio program. Is there anyway to check/verify 
whether Performance Counters were enabled during compile time? Is it still the 
case that they are off for apt-get packages for Ubuntu?

I have built a compiled from source GNU Radio Docker container. It is the 
current Main branch on Ubuntu 22.04. Thrift is installed and being found by 
cmake. I added '-DENABLE_PERFORMANCE_COUNTERS=True' to the Cmake call and 
turned everything on in the gnuradio-runtime.conf file. I also hard coded the 
thrift port to 9090 and port mapped out of the container. When I run 
gr-ctrlport-monitor I am able to info coming from the program running inside 
the container, like the edges. However, when I run gr-perf-monitorx I get the 
following:

ControlPort failed to connect. Check the config of your endpoint.
[ControlPort] on = True
[ControlPort] edges_list = True
[PerfCounters] on = True
[PerfCounters] export = True


Are there some additional steps I need to take to enable Performance Counters?

During compilation, I noticed this message, but I think it is in reference to 
the clock:

#8 5.302 -- Performing Test HAVE_MACH_ABSOLUTE_TIME
#8 5.337 -- Performing Test HAVE_MACH_ABSOLUTE_TIME - Failed
#8 5.337 -- Performing Test HAVE_QUERY_PERFORMANCE_COUNTER
#8 5.373 -- Performing Test HAVE_QUERY_PERFORMANCE_COUNTER - Failed
#8 5.374 --   High resolution timing supported through clock_gettime. 

Clearing a Blocks Buffers

[Luke Berndt]

Is there a good method for clearing or resetting a block’s buffers? 

I have a program that tunes to different frequencies and is also started & 
paused. I want to clear out any of the existing samples in the buffers between 
blocks to make sure I am getting the current signal in and not something that 
was left over. 

I have tried the following approach but it sometimes leads to segfaults with 
some blocks.  Can this be done? Is there a better way to do this or achieve the 
same results?

  gr::block_detail_sptr detail;
  gr::block_sptr grblock = cast_to_block_sptr(block);
  detail = grblock->detail();
  detail->reset_nitem_counters();

Using Selector to Mux and Demx in a single graph

[Luke Berndt]

I think I maybe trying to do something that is impossible. Can you have a graph 
 where it goes:
- a Source
- a Selector with one input and two outputs
   - Block 1 processing
   - Block 2 processing
- a Selector with two inputs and one output
- a Sink

I want to be able to dynamically switch between 2 different demodulators in the 
middle of a graph. Ideally I would be able to the combine streams from either 
active branch and only have a single sink. Is there a different approach that 
would work? Steam-Mux will not because it blocks waiting for input to 
interleave. 

If I have separate Sinks for Block 1 and Block 2 things work fine. If I use a 
second Selector to chose between Block 1 and Block 2’s output, no messages go 
through the graph to the Sink.

- Luke

Re: [Discuss-gnuradio] Improve FSK4 decodes in OP25

[Luke Berndt]

> 
> Or you've tweaked something (e.g. baseband level with a multiply
> const) such that the
> joint tracking loop in the 4FSK demod block loses track of the symbol clock?
> 
> IDK.
> 

Or… I am an idiot and when I was messing with OP25_FSK4_DEMOD block, I 
accidentally typed in 48800 for the system rate, for both blocks. Ugh! Sorry 
about that. Now I am getting 4 glorious lines.

Thanks again for all the help! It is great to be getting clear audio and having 
things look right on the charts.

 - Luke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 170, Issue 10

[Luke Berndt]

Andy - Thank you so much, this was extremely helpful. I switched to your RF
chain and I think it helped a bit. As you can probably guess, I am more of
a programmer than an RF expert.

It does look like Max has a branch of OP25 which has a deemphasis filter
that has been tuned for P25.
https://git.osmocom.org/op25/tree/op25/gr-op25_repeater/apps/tx/op25_c4fm_mod.py?h=max
It
might be tricky to port to C++ because it uses Numpy, but I am going to
give it a shot.

I do think you are right though, the underlying problem is that there is a
lot of noise. This may sound crazy, but I think it is coming from the USB
hub I am using. I know USB2 operates around 480MHz and I am trying to
record at 490MHz. I am going to experiment with my setup a bit to see if
this is it.

Thanks again for taking the time to put this all together. I will report
back on how things are going and if mange to get clean recordings.

 - Luke

On Sun, Jan 15, 2017 at 6:58 PM, Andy Walls 
wrote:

> Hi Luke,
>
> See the attached GRC for what can be done in GNURadio.
>
> 1. You need the baseband noise filter.
> 2. You may or may not need the deemphasis filter.  It appears to make
> things better,
> but it introduces receiver side ISI, since the filter doesn't get dumped
> at every symbol
> peak. (APCO 25 expects an integrate and dump deemphasis filter, this one
> just
> integrates).
> 3. You may wish to use the FM detector PLL instead of the Quad Demod
> block.  You
> can limit symbol peak frequency deviation using the Max Freq and Min Freq
> parameters.
> Currently, I have them set at +/-3 * 600 Hz * 190%.  Leave the loop
> bandwidth alone;
> it is set at symbol_rate/2 * 1.20 Hz = 2880 Hz, which is where the
> transmitter Nyquist
> filter should cut off.
>
> The signal you provided really does have a very poor SNR.  The attached
> low SNR
> png shows the best I could do with it.  There are some of the 4 levels
> visible in the chaos,
> but it's not good.  I have attached a png from a high SNR test signal for
> comparison.
>
> So what you can do "outside" of GNURadio:
>
> 1. Attach an external receiver bandpass filter for the 470 - 512 MHz safety
> band to your radio.  The only small, reasonably priced, off the shelf ones
> I could find
> are ceramic packages that are expected to be soldered to a board. :(
>
> 2. Set your gains on your SDR smartly to maximize your receiver noise
> figure.
> Set the RF gain as high as you can without clipping the IF stage, set the
> IF gain as high as you can without clipping the Base Band stage.  Set the
> Base
> Band gain as high as you can without clipping the ADC inputs.
>
> https://en.wikipedia.org/wiki/Friis_formulas_for_noise
> "... the overall noise figure of a radio receiver
> <https://en.wikipedia.org/wiki/Radio_receiver> is primarily established
> by the noise figure of its first amplifying stage. Subsequent stages have a
> diminishing effect on signal-to-noise ratio
> <https://en.wikipedia.org/wiki/Signal-to-noise_ratio>. "
>
> Regards,
> Andy
>
>
> On Thu, Jan 12, 2017 at 12:00 PM, 
> wrote:
>
>> Message: 6
>> Date: Wed, 11 Jan 2017 21:56:51 -0500
>> From: Luke Berndt
>> To: Marcus M?ller ,   GNURadio Discussion List
>> 
>> Subject: Re: [Discuss-gnuradio] Improve FSK4 decodes in OP25
>>
>> Thanks Marcus! I will try putting in a low pass in first after the Quad
>> demod. That BPF / Polyphase Channelizer approach sounds pretty cool too!
>>
>> I have attached a GRC file that I use for debugging and a link the raw
>> dump from a File Sink. The sample rate at the sink is 96k/s, the system
>> channel rate is 48k/s, with 10 samples per symbol. The FSK Level has to be
>> set to about 0.66.
>>
>> I am sure that some of the problem is that I don?t have a great signal
>> coming in, but if there is any additional processing I could do to improve
>> the reception that would be great.
>>
>>
>>
>> Wav file
>> https://www.dropbox.com/s/ncpz6wt8tubm2v3/32784-1484187802_
>> 4.90762e%2B08.wav?dl=0 <https://www.dropbox.com/s/ncp
>> z6wt8tubm2v3/32784-1484187802_4.90762e+08.wav?dl=0>
>>
>> Raw capture from a file sink
>> https://www.dropbox.com/s/810zj7pudc66yo3/32784-1484187802_
>> 4.90762e%2B08.raw?dl=0 <https://www.dropbox.com/s/810
>> zj7pudc66yo3/32784-1484187802_4.90762e+08.raw?dl=0>
>>
>>
>>
>> > On Jan 11, 2017, at 12:12 PM, Marcus M?ller 
>> wrote:
>> >
>> > Hi Luke,
>> >
>> > you don't happen to have a waterfall plot or a raw IQ recording?
>> > Quadrature demodulation isn't the most resilient to noise. So, a
>> 

Re: [Discuss-gnuradio] Improve FSK4 decodes in OP25

[Luke Berndt]

Thanks Marcus! I will try putting in a low pass in first after the Quad demod. That BPF / Polyphase Channelizer approach sounds pretty cool too!I have attached a GRC file that I use for debugging and a link the raw dump from a File Sink. The sample rate at the sink is 96k/s, the system channel rate is 48k/s, with 10 samples per symbol. The FSK Level has to be set to about 0.66.I am sure that some of the problem is that I don’t have a great signal coming in, but if there is any additional processing I could do to improve the reception that would be great.

debug.grc
Description: Binary data
Wav filehttps://www.dropbox.com/s/ncpz6wt8tubm2v3/32784-1484187802_4.90762e%2B08.wav?dl=0Raw capture from a file sink https://www.dropbox.com/s/810zj7pudc66yo3/32784-1484187802_4.90762e%2B08.raw?dl=0On Jan 11, 2017, at 12:12 PM, Marcus Müller <marcus.muel...@ettus.com> wrote:
  

  
  Hi Luke,you don't happen to have a waterfall plot or a raw IQ recording?
  
Quadrature demodulation isn't the most resilient to noise. So, a
  low-pass filter that makes sure that events that are sufficiently
  shorter than a symbol after the Quadrature demodulator would sound
  wise. Then again, I don't know the OP25 infrastructure overly
  well, so chances are the FSK4 demod already contains one.An alternative to your Quad FM demod would be a
  four-bandpasses-based decider. An easy way to build one is to
  either use four individual BPFs, or use one set of filter taps in
  the Polyphase Channelizer (which divides your f_sample_in  stream
  into four f_sample_in/4 -rate streams with channel centers). Just
  use a filter that would select the "zeroth" carrier. The magic of
  polyphase math will add three f_sample_in/4-shifted versions (you
  might need to use Rotator or similar to put the zeroth subcarrier
  at f=0). I have a "playing with channelizers" flow graph [1].
  Advantage of the polyphase channelizer is that it uses very little
  more ressources than a single bandpass filter would – basically,
  you get the three additional filters for the cost of a short FFT.
  Yay!Cheers,Marcus

[1] https://gist.github.com/babffaa88f54a7fba9b52fc09bda0462
    
    
On 01/11/2017 04:44 PM, Luke Berndt
  wrote:


  I am using the C++ OP25 libs to capture and record
the P25 transmissions from a trunked radio system ( https://github.com/robotastic/trunk-recorder
).


Transmission can either use 4-Level FSK or CPSK. I am
  getting great decodes from a system using CPSK but I am having
  a lot of trouble with a system using 4FSK.


At a high level, here is my 4FSK flow graph (https://github.com/robotastic/trunk-recorder/blob/master/trunk-recorder/recorders/p25_recorder.cc):
Xlating + LPF to roughly capture the channel
ARB Resampler to get the system sample rate
Quad FM Demod
Multiply Const - to get the right levels, -3 to 3
FSK4 Demod - from OP25
FSK4 Slicer - from OP25
OP25 Decode
it then converts it to what is needed to record it as a Wav
  file


Are there some obvious blocks I should add in to help
  condition the input better? I think the incoming levels may
  not be constant. There also seems to be occasional
  interference. Is there a block that will discard values above
  a certain range? It would be great to throw-away samples above
  3.5 or below -3.5.


Attached is a picture with what I think is an example of
  the interference.


Here is an example of a very clean recording: https://beta.openmhz.com/wmata?call-id=587652495833790100186198


Here is an example of a bad decode: https://beta.openmhz.com/wmata?call-id=58765250583379010018619c


Any tips would be greatly appreciated!!
  
- Luke


  

  
  
  
  
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



  

___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] unit-to-unit calls and op25/trunk-recorder

[Luke Berndt]

Hi Jason - I am the guy behind trunk-recorder. It is awesome to hear that it is 
working! This is probably something I messed and I just didn't set things up to 
recorder unit to unit calls. I don't think they happen much on my local system. 
If you are able to open an issue on the trunk-recorder github page, I think I 
can get this working. If you can post the channel grant message from 
Unitrunker, that would be huge. 

Thanks!

Luke

Sent from my iPhone

> On Aug 10, 2016, at 3:22 AM, Jason McHuff  wrote:
> 
> OK, I would like to say thank you for the help and that trunk-recorder is
> successfully recording calls.
> 
> However, it (and the OP25 Signal Scope app and certain hardware radio
> scanners) does not pick up unit-to-unit calls on the non-Motorola P25 system
> here.  Would someone be willing to write a patch to address this?  I'd be
> happy to record a bit of the control channel and make it available; I just
> need to know what format it should be in.  Moreover, I can run Unitrunker on
> Windows in parallel and tell what and when the channel grant is.
> 
> If there is a desire, I could possibly take this to the trunk-recorder
> GitHub page or the op25 Yahoo group.
> 
> 
> ___
> 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] Using USRP and Osmo sources

[Luke Berndt]

Has anyone used a USRP and Osmosdr source together on the same graph? I am 
trying. To run a HackRF and an Ettus b200 together and I am getting a lot of 
'D's. I have tried putting both at a low sampling rate but it doesn't seem to 
change things. I am running it on an i7 so there should be enough CPU. Could it 
be a USB issue? Could the drivers be interfering? 

Sent from my iPhone
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] squelch_base_cc.h not installed

[Luke Berndt]

I am trying to use the Power Squelch CC, but when I go to compile I get the
following error:

/opt/local/include/gnuradio/analog/pwr_squelch_cc.h:27:10: fatal
error: 'gnuradio/analog/squelch_base_cc.h' file not found
#include 

It looks like the squelch_base_cc.h is not getting installed when gnuradio
is built. squelch_base_ff.h does get installed.

I think the problem is that squelch_base_cc.h is not included in this
Cmake.txt: gnuradio/gr-analog/include/gnuradio/analog/CMakeLists.txt

Would adding squelch_base_cc.h here fix it?
https://github.com/gnuradio/gnuradio/blob/8ecfd13af0f55818d178fde17182de12b60ba4f1/gr-analog/include/gnuradio/analog/CMakeLists.txt#L43
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Performance diff between Null Sink & Copy Block

[Luke Berndt]

Hi - I am trying to create optional paths in my Gnuradio Flowgraph. I have 
found 2 ways of doing this in C++:
 - Doing a lock() / unlock() inside my heir_block2 and either connecting the 
items inside the block to the source of the block or connecting the source of 
the block to a null_sink.
- Putting a gr::blocks::copy inside my heir_block2 and either enabling or 
disabling when I want samples to go through the block.

With the null_sink I get almost no CPU load when the source is connect to the 
Null Sink. However with the Copy block I get a decent amount of CPU load when 
the block is set to disable.

I looked at the code and looks like a Copy Block set to disable is about the 
same as a Null Sink. they both just do nothing with the incoming samples.

Why is the Copy Block using so much more CPU? Is it possible for it to have the 
same CPU load as a null sink?

Is there are better way of doing this? Should I write a custom block?

Thanks,

Luke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Locking TopBlock stops WavFile-Sink

[Luke Berndt]

> Yes, a lock/unlock event affects the whole flowgraph, by necessity.
> 
> Reconfiguring flowgraphs should be considered a very big hammer, often
> used in cases that can be solved some less invasive way.

Just in case anyone is looking for a less invasive way to dynamically configure 
a graph…

I just tried out Copy block and it seems to be a great way to turn on and off 
segments of a flow graph. I was locking & unlocking a graph to remove and add 
blocks.

This seems more elegant and prevents any problems with the WavFile-Sink.

http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1copy.html 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Locking TopBlock stops WavFile-Sink

[Luke Berndt]

I will give it a try and see if I can make a start() that does this.

One last question - does calling lock() in a HeirBlock2 just lock and call
stop() on the internal blocks of the HeirBlock2 graph? or does it bubble up
all the way to the TopBlock and cause a lock there?

I am trying to figure out why calling lock() on one instance of a HeirBlock
cause all the other instances to lock().

On Mon, Jan 5, 2015 at 10:58 AM, Tom Rondeau  wrote:

> On Mon, Jan 5, 2015 at 10:44 AM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> Hi,
>>
>> > You could try and modify the code to overload the start() function to
>> > open/reopen the file again (can't say for sure this will be safe with a
>> wav
>> > file, though). Though probably easiest to create your own block as part
>> of
>> > any oot module you've built for your projects.
>>
>> I'd tend to say that the included block should support that. Since
>> apparently multiple start()/stop() calls by the scheduler is something
>> blocks should handle gracefully.
>>
>> I'd assume stop() was made to close the file to ensure the header is
>> properly written.
>> But it could just update the header and seek back to the end without
>> actually closing the file and let the destructor do the close on the
>> fd.
>>
>>
>> Cheers,
>>
>>Sylvain
>>
>
> This sounds like a good idea.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Locking TopBlock stops WavFile-Sink

[Luke Berndt]

Awesome! That is totally it.

I went back and checked and the 3.6 version of wavfile_sink_impl does not
have a stop function. It only closes the file when close() is called or the
destructor.

This is a pretty big change from 3.6 to 3.7 and I didn't see it documented
anywhere. Is this something I can add to the 3.6 -> 3.7 guide in the wiki?
Is there a better place to capture some of the lower level changes?

Are there any good guides that walk through the flows for high level
functions? Like what calling lock() triggers in the blocks and the
scheduler? It would make it a lot easier to walk through the code.

In order to solve my problem, it looks like I should create a custom
version of wavfile_sink that doesn't have stop().

Thanks again!

 - Luke


On Mon, Jan 5, 2015 at 7:34 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
>
> When there is a lock()/unlock() cycle, the ->stop() will end up being
> called on all the flowgraph() blocks.
>
> The wavsink block does implement stop() and that's where it closes the
> file and updates the wavheader.
>
> But there is no implementation for start(), it actually opens the file
> in the constructor, so it can't resume.
>
>
> Cheers,
>
> Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Locking TopBlock stops WavFile-Sink

[Luke Berndt]

It looks like there is an issue where locking/unlocking the TopBlock causes 
WavFile-Sink to stop recording. A plain File-Sink does not have this problem. 
This problem is new to 3.7 and didn’t exist in 3.6. Is this the intended 
behavior? I am doing something wrong? Should I be using Stop/Wait?

I have put together an even more simplified C++ program here: 
https://github.com/robotastic/topblock-lock 

When you run it, the wav file will stop growing after 5 secs when the graph is 
locked/unlocked and the file sink raw file will keep growing.

To compile, do ‘cmake .’ then ‘make’ then ‘topblock-lock'

Here is the basic code:

time_t last_monkey;
 
gr::top_block_sptr tb;
gr::blocks::vector_source_f::sptr src;
gr::blocks::throttle::sptr throttle;
gr::blocks::wavfile_sink::sptr wav_sink;
gr::blocks::file_sink::sptr raw_sink;
char filename[160];
char raw_filename[160];

volatile sig_atomic_t exit_flag = 0;

void exit_interupt(int sig){ // can be called asynchronously
  exit_flag = 1; // set flag
}



int main(int argc, char **argv)
{

std::string device_addr;
double  samp_rate=32000;

signal(SIGINT, exit_interupt);

tb = gr::make_top_block("Main");

vector floatVector;
srand((unsigned)time(NULL));

for (int i =0; i < 2000; i++){
float r = static_cast  (rand()) / static_cast  (RAND_MAX);
floatVector.push_back(r);
}
src = gr::blocks::vector_source_f::make(floatVector,true);
throttle = gr::blocks::throttle::make(sizeof(float), samp_rate);

std::stringstream path_stream;
path_stream << boost::filesystem::current_path().string() <<  
"/recordings";

boost::filesystem::create_directories(path_stream.str());
sprintf(filename, "%s/main-0.wav", path_stream.str().c_str());
wav_sink = gr::blocks::wavfile_sink::make(filename,1,samp_rate,16);
sprintf(raw_filename, "%s/main-0.raw", 
path_stream.str().c_str());
raw_sink = gr::blocks::file_sink::make(sizeof(float), raw_filename);


tb->connect(src,0,throttle,0);
tb->connect(throttle,0,wav_sink,0);
tb->connect(throttle,0,raw_sink,0);

last_monkey = time(NULL);

tb->start();

while (1) {
if(exit_flag){ 
printf("\n Signal caught!\n");
tb->stop();
return 0;
}
if ((time(NULL) - last_monkey) > 10) {
last_monkey = time(NULL);
tb->lock();
tb->unlock();
}   
}
  // Exit normally.
return 0;   
}___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] HeirBlock2 Lock/Unlock breaks WavSink

[Luke Berndt]

Short story - doing a Lock/Unlock on a HeirBlock2 to reconfigure its internal 
flow graph stops a WavFile_Sink that is in it until a new wav file is opened. 
It doesn’t affect any File_Sinks that are in the graph. If there are multiple 
instances of the HeirBlock2 running, it will stop the WavFile_Sink running in 
all the instances. This didn’t happen in 3.6, but started in 3.7. I have an 
extremely simplified sample program that demonstrates the problem: 
https://github.com/robotastic/multi-wav 


Long Story - I am recording multiple audio channels from my SDR to capture my 
local fire departments radio system. I have to add and remove multiple 
recorders at different freq offsets to catch the different transmissions as the 
start and stop. To do that I have a bunch of HeirBlock2 based graphs that I 
attach to the source. When they are not being used I lock the block and connect 
the block source to a null sink. When they are needed, I connect all the 
internal blocks together and tune the xlating offset.

The sample program I wrote shows this. It starts up 6 recording blocks. After 
10 seconds it will randomly lock/unlock one of the recording blocks. You will 
see that all of the WavFile_Sinks in each instance of the block stops 
recording. However the file_sinks that are attached inside the Block keep on 
recording fine. You will see the raw file size continue to grow and the wav 
file size stop.

The sample program is in C++. You should be able to download, do ‘cmake .’ and 
then ‘make’ and then ‘./multi-wav’  Then look in the ‘recordings’ directory.

It seems like there is a problem with GnuRadio and HeirBlock Locking in 3.7…. 
or wavfile_sink. Also possible I did something really dumb. Any thoughts?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Change in 3.7 with buffers

[Luke Berndt]

I tried to build everything out as a GRC graph. I don’t think it has anything 
to do with the wav file sink. I recorded the raw signal and everything is 
working fine until it gets to the vocoder block, DSD. It handles decoding fine 
when there is only one instance, but when there are multiple instance of the 
block running at once, they step on each I think. So when one block stops it 
seems to be stopping the wav file for another.

Each of the blocks store state information for the radio call it is decoding. 
Did anything change between 3.6 and 3.7 with the way blocks are initialized, 
where some of the class variables are shared between multiple instances? Is 
there someway multiple instances of a single block type might be combined to 
save on memory?

The DSD block is created and return using the standard make and 
gnuradio::get_initial_sptr() pattern.

The weird part is that the same code logic works great in 3.6. I compared 
everything in diff and the only meaningful difference is the header changes for 
3.7 classes.

 - Luke

> On Nov 11, 2014, at 3:08 AM, Martin Braun  wrote:
> 
> On 11/11/2014 05:27 AM, Luke Berndt wrote:
>> Sorry - I seem to keep running into weird corner cases with my
>> program. I am having an issue were I am trying to run multiple graphs
>> off the same source, and decoding different channels digital audio to
>> wav files. It worked great under 3.6, but with 3.7 they are cutting
>> off prematurely.
>> 
>> I will keep digging deeper, but I just wanted to check first to see
>> if this has happened to anyone or if there were any obvious changes
>> to blocks. If there anything new and special I might have to do to
>> flush buffers in blocks once I tell it to stop recording and close
>> the file? I am using wav_file->close();. It is a pretty standard
>> graph using quad_demo to a gr_DSD block to decode the digital audio
>> and then a wav_file_sink.
> 
> This behaviour was not (intentionally) changed. However, calling close()
> on a wav file block will not flush any buffers (and never has), it'll
> just write the headers to the WAV file. That it's cut off doesn't strike
> me as odd, but I'm not sure why it would have worked before. Did you
> change buffer sizes?
> 
> 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

[Discuss-gnuradio] Change in 3.7 with buffers

[Luke Berndt]

Sorry - I seem to keep running into weird corner cases with my program. I am 
having an issue were I am trying to run multiple graphs off the same source, 
and decoding different channels digital audio to wav files. It worked great 
under 3.6, but with 3.7 they are cutting off prematurely. 

I will keep digging deeper, but I just wanted to check first to see if this has 
happened to anyone or if there were any obvious changes to blocks. If there 
anything new and special I might have to do to flush buffers in blocks once I 
tell it to stop recording and close the file? I am using wav_file->close();. It 
is a pretty standard graph using quad_demo to a gr_DSD block to decode the 
digital audio and then a wav_file_sink.

 - Luke



___
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

[Luke Berndt]

That fixed it!!

Nick & Andy - thank you both so much for looking into it. Without your help, 
there is no way I would have fixed this… and without Nick’s code I couldn’t 
have built it in the first place.

 - Luke

> On Nov 4, 2014, at 8:28 PM, Nick Foster  wrote:
> 
> Red face over here.
> 
> There was a bug in correlate_access_code_tag -- which only gr-smartnet and 
> gr-ais use, so far as I know. The fix was pulled into master a couple of days 
> ago. This could explain the discrepancy you're seeing in the preamble mark.
> 
> Pull latest GR master, build, and see if it fixes what you're seeing.
> 
> --n
> 
> On Tue, Nov 4, 2014 at 5:19 PM, Andy Walls  <mailto:a...@silverblocksystems.net>> wrote:
> On Mon, 2014-11-03 at 22:13 -0500, Luke Berndt wrote:
> > Thanks Andy! Good catch - I made the changes you suggested. I was just
> > doing a simple back of the envelope calculation to come up with
> > channel size. It does look like cleans things up and adding the
> > waterfall graphs does make it easier to see. Unfortunately, it does
> > seem to change the decoding. I am still getting the same amount of CRC
> > errors.
> >
> > Did the overall signal look right, like something that should be decodable?
> 
> So I put the output of the FLL into a quad demod block and compared its
> output to the PLL Freq det output.  They are pretty much in line, except
> the quadrature demod block output shows occasional burst of noise for a
> few symbol times where the transmission must have stopped and restarted.
> The PLL freq detect block just makes something up during these times.
> So that seems generally OK.
> 
> 
> 
> > Anything else I should try?
> 
> Your PLL freq detector block output is swinging between -2 and 2.  You
> might want to reduce the max and min freq by a factor of 2, so that the
> clock recovery block sees inputs limited to +/- 1.0.  See Nick's
> recommendation here:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00473.html 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00473.html>
> 
> So after i did that, what I really noticed is that the correlator is
> just not marking preambles properly.  See the top plot of the attached
> to window shots:  Preamble_marked_late_twice.png and
> Preamble_marked_early.png
> 
> If the deinterleaver and/or crc block isn't searching around for where
> the preamble really is, well that would explain it.
> 
> Regards,
> Andy
> 
> >  - Luke
> >
> > >
> > > Hi Luke,
> > >
> > > I have not built the SmartNet blocks yet, but:
> > >
> > > Your low pass filter looks way too wide and you'll get aliases when you
> > > decimate by 185.  2 Msps / 185 = 10.81 ksps, so the Nyquist frequency is
> > > 5.405 kHz.  I winged this is as a low pass filter and things looked
> > > better:
> > >
> > > firdes.low_pass_2(1, samp_rate, 4500, 1000, 60, firdes.WIN_HANN, 6.76)
> > >
> > > The 60 dB down may be overkill, you can make it smaller for a filter
> > > with less delay.
> > >
> > > I found an offset slider value of -15k made things look about centered
> > > manually.
> > >
> > > You might want to put a waterfall sink before and after the FLL
> > > Band-Edge filter to observe how it is making the spectrum wobble around
> > > a little. If you change your offset slider, you can see the FLL
> > > band-edge filter centering things back up; so that looks like it is
> > > working.
> > >
> > > Regards,
> > > Andy
> > >
> >
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
> <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

[Luke Berndt]

This is awesome! I just pulled master and I am recompiling it right now. Thanks 
you both so much for the help.

I clearly still have some tuning work to do either way, but it would be great 
to get move up to 3.7. I will let you know if this clears it up. I have my 
fingers crossed that it will.

> On Nov 4, 2014, at 8:19 PM, Andy Walls  wrote:
> 
> On Mon, 2014-11-03 at 22:13 -0500, Luke Berndt wrote:
>> Thanks Andy! Good catch - I made the changes you suggested. I was just
>> doing a simple back of the envelope calculation to come up with
>> channel size. It does look like cleans things up and adding the
>> waterfall graphs does make it easier to see. Unfortunately, it does
>> seem to change the decoding. I am still getting the same amount of CRC
>> errors.
>> 
>> Did the overall signal look right, like something that should be decodable? 
> 
> So I put the output of the FLL into a quad demod block and compared its
> output to the PLL Freq det output.  They are pretty much in line, except
> the quadrature demod block output shows occasional burst of noise for a
> few symbol times where the transmission must have stopped and restarted.
> The PLL freq detect block just makes something up during these times.
> So that seems generally OK.
> 
> 
> 
>> Anything else I should try?
> 
> Your PLL freq detector block output is swinging between -2 and 2.  You
> might want to reduce the max and min freq by a factor of 2, so that the
> clock recovery block sees inputs limited to +/- 1.0.  See Nick's
> recommendation here:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00473.html 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00473.html>
> 
> So after i did that, what I really noticed is that the correlator is
> just not marking preambles properly.  See the top plot of the attached
> to window shots:  Preamble_marked_late_twice.png and
> Preamble_marked_early.png
> 
> If the deinterleaver and/or crc block isn't searching around for where
> the preamble really is, well that would explain it.
> 
> Regards,
> Andy
> 
>> - Luke
>> 
>>> 
>>> Hi Luke,
>>> 
>>> I have not built the SmartNet blocks yet, but:
>>> 
>>> Your low pass filter looks way too wide and you'll get aliases when you
>>> decimate by 185.  2 Msps / 185 = 10.81 ksps, so the Nyquist frequency is
>>> 5.405 kHz.  I winged this is as a low pass filter and things looked
>>> better:
>>> 
>>> firdes.low_pass_2(1, samp_rate, 4500, 1000, 60, firdes.WIN_HANN, 6.76)
>>> 
>>> The 60 dB down may be overkill, you can make it smaller for a filter
>>> with less delay.
>>> 
>>> I found an offset slider value of -15k made things look about centered
>>> manually.
>>> 
>>> You might want to put a waterfall sink before and after the FLL
>>> Band-Edge filter to observe how it is making the spectrum wobble around
>>> a little. If you change your offset slider, you can see the FLL
>>> band-edge filter centering things back up; so that looks like it is
>>> working.
>>> 
>>> Regards,
>>> Andy
>>> 
>> 
> 
> 

___
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

[Luke Berndt]

Thanks Andy! Good catch - I made the changes you suggested. I was just doing a 
simple back of the envelope calculation to come up with channel size. It does 
look like cleans things up and adding the waterfall graphs does make it easier 
to see. Unfortunately, it does seem to change the decoding. I am still getting 
the same amount of CRC errors.

Did the overall signal look right, like something that should be decodable? 

Anything else I should try?

 - Luke

> 
> Hi Luke,
> 
> I have not built the SmartNet blocks yet, but:
> 
> Your low pass filter looks way too wide and you'll get aliases when you
> decimate by 185.  2 Msps / 185 = 10.81 ksps, so the Nyquist frequency is
> 5.405 kHz.  I winged this is as a low pass filter and things looked
> better:
> 
> firdes.low_pass_2(1, samp_rate, 4500, 1000, 60, firdes.WIN_HANN, 6.76)
> 
> The 60 dB down may be overkill, you can make it smaller for a filter
> with less delay.
> 
> I found an offset slider value of -15k made things look about centered
> manually.
> 
> You might want to put a waterfall sink before and after the FLL
> Band-Edge filter to observe how it is making the spectrum wobble around
> a little. If you change your offset slider, you can see the FLL
> band-edge filter centering things back up; so that looks like it is
> working.
> 
> Regards,
> Andy
> 


___
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

[Luke Berndt]

Thanks! I clearly have a lot of RF theory to read up on. 

The Band Edge FLL works great for me too, on 3.6. Does anyone know if there 
were changes to it or surrounding blocks in 3.7 that would make it stop working?

I have a pretty strong, clean signal. 

Sent from my iPhone

> On Oct 18, 2014, at 11:00 AM, Nick Foster  wrote:
> 
> Figured I'd chime in since I wrote the code in question. The band edge FLL is 
> probably the wrong thing to use, but it did work surprisingly well for my 
> local setup (at very high SNR), so I left it in. The square-and-FFT block 
> works great for MSK, but Smartnet isn't MSK, it's FSK, and its lack of phase 
> coherence (and variable deviation) mean you won't see those nice 1/2-bitrate 
> FFT spikes.
> 
> As Andy points out, the "right" answer is to correlate against the modulated 
> preamble and develop phase, frequency, and timing estimates from the known 
> preamble.
> 
> --n
> 
> 
>> On Oct 18, 2014 6:41 AM, "Andy Walls"  wrote:
>> On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
>> wrote:
>> 
>> > Message: 33
>> > Date: Fri, 17 Oct 2014 07:37:25 -0700
>> > From: John Malsbury 
>> > To: Luke Berndt 
>> > Cc: "Discuss-gnuradio@gnu.org List" 
>> > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
>> > Message-ID:
>> >   
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > 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..
>> 
>> John and Luke,
>> 
>> Yup.  GMSK doesn't have any narrow and strong spectral feature on which
>> one can lock a PLL.  (And the band-edge FLL is the wrong thing to use
>> too.)
>> 
>> You can however get a spectral feature from the square of the GMSK
>> signal.  *Assuming* you have an approximately random bit stream,
>> squaring the GMSK signal gives you spectral peaks at f_c +/- f_b/2,
>> where f_c is the center frequency and f_b is your bit rate.  See the
>> attached "GMSK_squared_spectrum.png" which shows the spectra from a
>> random bit stream.
>> 
>> So you can get a non-data-aided coarse frequency correction doing
>> essentially what older versions of gr-ais did.  See the attached
>> "square_and_fft_freq_sync.grc.png".  The gr-ais "freqest" block is the
>> only non-stock gnuradio block and it just walks the FFT looking for the
>> spectral peaks at +/- f_b/2 and outputs a frequency correction values
>> based on how many FFT bins the peaks are offset from the expected center
>> frequency.
>> 
>> The major tradeoff is the length of the FFT:
>> 1. More FFT points gives you finer resolution bins and a finer
>> correction.
>> 2. More FFT points protects against pathological data sequences (e.g. a
>> long run of 0's) that give different spectral peaks which screw up the
>> correction.
>> 3. Fewer FFT points ensures the start and end of bursts get the proper
>> correction as the correction reacts faster to the transition from
>> dead-air to modulated signal.
>> 4. Fewer FFT points ensures faster reaction to changes in frequency
>> offset.
>> 
>> 
>> Although, if you have a known preamble to inspect, data-aided carrier
>> frequency offset correction is way better than the above non-data-aided
>> stuff.
>> 
>> Regards,
>> Andy
>> 
>> > Anyway, the GMSK block might be a good place to start.
>> >
>> > -John
>> >
>> > On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury 
>> > > > > 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 F

Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[Luke Berndt]

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  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 
>>> 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

[Luke Berndt]

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 
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

Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[Luke Berndt]

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  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::pi();
> 
>   cout << "Control channel offset: " << offset << endl;
>   cout << "Decim: " << decim << endl;
>   cout << "Samples per symbol: " << sps << endl;
> 
>   std::vector 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();
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[Luke Berndt]

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::pi();

cout << "Control channel offset: " << offset << endl;
cout << "Decim: " << decim << endl;
cout << "Samples per symbol: " << sps << endl;

std::vector 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();___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ctrlport-monitor: radio.get threw exception (math domain error).

[Luke Berndt]

Not a problem - It was under a VM, so that is probably what was causing it.
I ran it at home on bare metal with a HackRF and didn't have any issues.


On Fri, Apr 11, 2014 at 4:10 PM, Tom Rondeau  wrote:

> On Wed, Mar 26, 2014 at 4:28 PM, Luke Berndt  wrote:
>
>> I get the following error when trying to the run gr-perf-monitorx against
>> a flow graph that has an RTL_SDR radio as the source. I recompiled both
>> rtl_sdr and gr_osmosdr after enabling performance counters in gnuradio.
>>
>> The odd thing is that it works fine when I do not have an RTL_SDR radio
>> attached. In that instance gr-osmosdr simply attaches a null source
>> instead. This seems to point to the RTL_SDR source. Has anyone succesfully
>> used gr-perf-monitorx with a RTL_SDR source?
>>
>> Thanks
>>
>> Luke
>>
>> PS - also just in case anyone else tries, 'perf top' doesn't work in a
>> VM...
>>
>
>
> Luke,
>
> This gut buried in my inbox. Any updates on your success with this? Are
> you running into this on a VM? It might be something related to that,
> anyways.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Solution for SegFault with Lock / Unlock in 3.7 C++

[Luke Berndt]

I am using Boost 1.53, on Ubuntu 13.10 via apt-get. When I was running it
under GnuRadio 3.6, I think I was running Boost 1.49, but it got upgrade
because I think it is not compatible with GR 3.7?

Would it be worth it to try build from source for Boost 1.48 or 1.55?


On Fri, Mar 28, 2014 at 12:54 PM, Tim Newman  wrote:

> What version of boost are you using?
>
> Tim
>
>
> On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt  wrote:
>
>> I was wondering if there has been any progress or work arounds for Bug
>> 598 in 3.7?
>>
>> http://gnuradio.org/redmine/issues/598
>>
>> The issue is the GnuRadio will segfault if there are too many Lock /
>> Unlocks.
>> I am having it happen after 6 - 10 lock/unlocks.
>>
>> My program is a C++ program that records trunked radio calls and I need
>> to be able to dynamically connect / disconnect recording flowgraphs as new
>> calls are started. The program works fine under 3.6.
>>
>> I was wondering if there are any work arounds I should try. I have tried
>> using tb->stop,  tb->wait, tb->start, but it still crashes. Is there some
>> other way to dynmically connect & disconnect blocks that doesn't require
>> lock / unlock?
>>
>> Is there an ETA when this would be fixed? Anything I can help on? I am
>> going to have to go back to 3.6 if I can't figure out a solution.
>>
>> Thanks!
>>
>>  - Luke
>>
>>
>>
>>
>> ___
>> 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] Solution for SegFault with Lock / Unlock in 3.7 C++

[Luke Berndt]

I was wondering if there has been any progress or work arounds for Bug 598
in 3.7?

http://gnuradio.org/redmine/issues/598

The issue is the GnuRadio will segfault if there are too many Lock /
Unlocks.
I am having it happen after 6 - 10 lock/unlocks.

My program is a C++ program that records trunked radio calls and I need to
be able to dynamically connect / disconnect recording flowgraphs as new
calls are started. The program works fine under 3.6.

I was wondering if there are any work arounds I should try. I have tried
using tb->stop,  tb->wait, tb->start, but it still crashes. Is there some
other way to dynmically connect & disconnect blocks that doesn't require
lock / unlock?

Is there an ETA when this would be fixed? Anything I can help on? I am
going to have to go back to 3.6 if I can't figure out a solution.

Thanks!

 - Luke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ctrlport-monitor: radio.get threw exception (math domain error).

[Luke Berndt]

I get the following error when trying to the run gr-perf-monitorx against a
flow graph that has an RTL_SDR radio as the source. I recompiled both
rtl_sdr and gr_osmosdr after enabling performance counters in gnuradio.

The odd thing is that it works fine when I do not have an RTL_SDR radio
attached. In that instance gr-osmosdr simply attaches a null source
instead. This seems to point to the RTL_SDR source. Has anyone succesfully
used gr-perf-monitorx with a RTL_SDR source?

Thanks

Luke

PS - also just in case anyone else tries, 'perf top' doesn't work in a VM...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Performance drop with upgrade to 3.7

[Luke Berndt]

Thanks Guys! I am rebuilding with Debug turned on and I also enabled
Control Ports in the compile. Hopefully this should help highlight the
major CPU hogs.

Marcus - build-gnuradio is an awesome script. Thank you so much for the
time you put into keeping it current. It is the only reliable way I have
found to install GnuRadio on Ubuntu 13.10.

 - Luke


On Wed, Mar 26, 2014 at 12:45 PM, Marcus Leech  wrote:

> It was on my list to change the build-types to "debug" (to provide
> symbols).  I can't remember whether I did that or not.
>   Other than disk space, there's no down-side that I can see
>
>
>  on Mar 26, 2014, *West, Nathan*  wrote:
>
> On Tue, Mar 25, 2014 at 2:27 PM, Luke Berndt  wrote:
> > Thanks - I am running an quad-core Intel I5 laptop. It is running Ubuntu
> > 13.10. I also have it running on a VM on my 8 Core I7 Macbook.
> >
> > Do you have any pointers or links on using oprofile with gnuradio? I
> found
> > some material on using GR Performance Counters, but I haven't had a
> chance
> > to try.
> >
> > I am going to working on learning how to profile using the VM. In the
> > meantime, I rolled back the bare metal machine so I can keep my site up.
> >
> > I installed 3.7 using the build-gnuradio script. When I reinstalled
> 3.6.5,
> > also using build-gnuradio, the performance was still high. I am
> wondering if
> > it actually has something to do with libraries being upgraded. I know the
> > script upgraded me from Boost 1.49 to 1.53. Are there some other
> libraries
> > that could have a perf impact? ITPP?
> >
>
> I'm not sure what release type build-gnuradio is using, but you want
> to do a build that preserves symbols. After that the easiest way I
> know of to get a quick glance at what's causing performance issues is
> to run 'perf top'. Just run your flowgraph then start up perf top and
> whatever is hogging CPU will rise to the top of the list
>
> Nathan
>
> ___
> 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] Performance drop with upgrade to 3.7

[Luke Berndt]

Thanks - I am running an quad-core Intel I5 laptop. It is running Ubuntu
13.10. I also have it running on a VM on my 8 Core I7 Macbook.

Do you have any pointers or links on using oprofile with gnuradio? I found
some material on using GR Performance Counters, but I haven't had a chance
to try.

I am going to working on learning how to profile using the VM. In the
meantime, I rolled back the bare metal machine so I can keep my site up.

I installed 3.7 using the build-gnuradio script. When I reinstalled 3.6.5,
also using build-gnuradio, the performance was still high. I am wondering
if it actually has something to do with libraries being upgraded. I know
the script upgraded me from Boost 1.49 to 1.53. Are there some other
libraries that could have a perf impact? ITPP?




On Mon, Mar 24, 2014 at 11:35 AM, West, Nathan
wrote:

> On Mon, Mar 24, 2014 at 7:17 AM, Luke Berndt  wrote:
> > Hi - I just upgraded to 3.7.3 using the build-gnuradio script from
> 3.6.5.1.
> > I am using it to run a C++ App that captures all the radio
> communications on
> > a Moto SmartNet system. I upgraded all my code to work with the 3.7
> naming
> > scheme and got everything to compile and run. Everything runs in 3.7,
> but I
> > am seeing a lot more CPU usage, almost a whole additional core.
> >
> > Are there an obvious things I should check where blocks changed
> > significantly from 3.6 to 3.7?
> >
> > The main code is here:
> > https://github.com/robotastic/smartnet-recorder/tree/3.7
> >
> > And the codec is here:
> > https://github.com/robotastic/gr-dsd/tree/3.7
> >
> > I put together the general flow graph below. Are there any blocks where I
> > could be shooting myself in the foot? Is it better to do xlating or
> > sig_source & multiply_cc? The source bandwidth is 5MHz.
> >
> > Decode Control Channel: [
> > https://github.com/robotastic/smartnet-recorder/blob/3.7/smartnet.cc ]
> > multiply_cc ( OsmoSDR(HackRF)  +analog::sig_source_c )
> > gr::filter::fir_filter_ccf
> > gr::digital::fll_band_edge_cc
> > gr::analog::pll_freqdet_cf
> > gr::digital::clock_recovery_mm_ff
> > gr::digital::binary_slicer_fb
> > gr::digital::correlate_access_code_tag_bb
> > smartnet_deinterleave
> > smartnet_crc
> >
> > Decode digital voice channel: [
> >
> https://github.com/robotastic/smartnet-recorder/blob/3.7/logging_receiver_dsd.cc
> > ]
> > tb->connect( OsmoSDR(HackRF) )
> > gr::filter::freq_xlating_fir_filter_ccf
> > gr::filter::rational_resampler_base_ccf
> > gr::analog::quadrature_demod_cf
> > gr::filter::fir_filter_fff
> > dsd_make_block_ff [
> > https://github.com/robotastic/gr-dsd/blob/3.7/lib/dsd_block_ff.cc ]
> > gr::blocks::wavfile_sink
> >
> >
> >
> >
>
> What processor and OS are you running on? I suggest you start by
> profiling your flowgraphs with something like oprofile/perf or control
> port. Profiling with 3.7 is the first step and may be all that's
> necessary if something really stands out, otherwise comparing results
> of 3.6.5.1 and 3.7 would be good.
>
> I'd be interested in seeing your results.
>
>
> Nathan
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Performance drop with upgrade to 3.7

[Luke Berndt]

Hi - I just upgraded to 3.7.3 using the build-gnuradio script from 3.6.5.1.
I am using it to run a C++ App that captures all the radio communications
on a Moto SmartNet system. I upgraded all my code to work with the 3.7
naming scheme and got everything to compile and run. Everything runs in
3.7, but I am seeing a lot more CPU usage, almost a whole additional core.

Are there an obvious things I should check where blocks changed
significantly from 3.6 to 3.7?

The main code is here:
https://github.com/robotastic/smartnet-recorder/tree/3.7

And the codec is here:
https://github.com/robotastic/gr-dsd/tree/3.7

I put together the general flow graph below. Are there any blocks where I
could be shooting myself in the foot? Is it better to do xlating or
sig_source & multiply_cc? The source bandwidth is 5MHz.

*Decode Control Channel:* [
https://github.com/robotastic/smartnet-recorder/blob/3.7/smartnet.cc ]
multiply_cc ( OsmoSDR(HackRF)  +analog::sig_source_c )
gr::filter::fir_filter_ccf
gr::digital::fll_band_edge_cc
gr::analog::pll_freqdet_cf
gr::digital::clock_recovery_mm_ff
gr::digital::binary_slicer_fb
gr::digital::correlate_access_code_tag_bb
smartnet_deinterleave
smartnet_crc

*Decode digital voice channel:* [
https://github.com/robotastic/smartnet-recorder/blob/3.7/logging_receiver_dsd.cc]
tb->connect( OsmoSDR(HackRF) )
gr::filter::freq_xlating_fir_filter_ccf
gr::filter::rational_resampler_base_ccf
gr::analog::quadrature_demod_cf
gr::filter::fir_filter_fff
dsd_make_block_ff [
https://github.com/robotastic/gr-dsd/blob/3.7/lib/dsd_block_ff.cc ]
gr::blocks::wavfile_sink
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Valgrind & gr_fir_fff_simd::set_taps - memory leak

[Luke Berndt]

I am trying to track down an insidious little memory leak in a Block that
wraps the DSD vocoder. I have run Valgrind against it and didn't find
anything obvious. Valgrind didn't like the way memory was being assigned by
set_taps and it seems like this came up in a previous thread too:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00015.html

It doesn't look like there was a definitive answer if this was a real
problem or just Valgrind getting confused.

For Background:
I am running GNURadio 3.6.5.1 and my program is all in C++ without any
python. The DSD Vocoder block run the DSD program (which is a C program) in
a pthread and passes it samples using a shared array and some mutex. For
each separate talkgroup conversation on a trunking radio system, the
TopBlock gets locked, a new logging flow with the DSD block in it gets
created and then connected. When the conversation is over the tb get
locked/unlocked and the flows is destroyed. Are there any obvious gotchas
that might leak with this approach? I am using detached threads to run
DSDand deleting all of the
mutex/cond I init.

Here is the Valgrind output concerning the set_taps:

Decoding only P25 Phase 1 frames.
Enabling only C4FM modulation optimizations.
 Recv [ 0 ]   Tg: 1616  Freq: 856.6
==5138== Thread 9:
==5138== Invalid read of size 8
==5138==at 0x4F3F48C: float_dotprod_sse (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F40770: gr_fir_fff_generic::filterN(float*, float const*,
unsigned long) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F41D02: gr_fir_filter_fff::work(int, std::vector >&, std::vector >&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F29EF3: gr_sync_decimator::general_work(int,
std::vector >&, std::vector >&, std::vector
>&) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F099D5: gr_block_executor::run_one_iteration() (in /usr
/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F33B32: gr_tpb_thread_body::gr_tpb
_thread_body(boost::shared_ptr, int) (in /usr/local/lib/
libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F27077:
boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::function_buffer&)
(in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x581F14E: boost::detail::thread_data
>::run() (in /usr/local/lib/libgruel-3.6.5.1.so.0.0.0)
==5138==by 0x76716E8: ??? (in /usr/lib/libboost_thread.so.1.49.0)
==5138==by 0x5A39F8D: start_thread (pthread_create.c:311)
==5138==by 0x7394E1C: clone (clone.S:113)
==5138==  Address 0xfc63288 is 88 bytes inside a block of size 95 alloc'd
==5138==at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck
-amd64-linux.so)
==5138==by 0x4F79FBE: malloc16Align (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F7A009: calloc16Align (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3D435: gr_fir_fff_simd::set_taps(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3D553: gr_fir_fff_simd::gr_fir_fff_simd(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3D7F8: gr_fir_fff_sse::gr_fir_fff_sse(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3BAE0:
gr_fir_sysconfig_x86::create_gr_fir_fff(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F41FF5: gr_fir_filter_fff::gr_fir_filter_fff(int,
std::vector > const&) (in /usr/local/lib/
libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F4217B: gr_make_fir_filter_fff(int, std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x482D55: log_dsd::log_dsd(float, float, long, int)
(logging_receiver_dsd.cc:76)
==5138==by 0x482531: make_log_dsd(float, float, long, int)
(logging_receiver_dsd.cc:8)
==5138==by 0x46116F: main (smartnet.cc:394)


And here is the code that creates the fir_filter_fff (in the
constructorfor the logger):

const float a[] = { 0.1, 0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1};
std::vector data( a,a + sizeof( a ) / sizeof( a[0] ) );
sym_filter = gr_make_fir_filter_fff(1, data);
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Luke Berndt]

I think I may have figured it out. It has to do with how the signal processing 
block that goes around the vocoder was written. The general_work function for 
gr_block classes takes in a requested number of outputs and also returns back 
how many output items were produced. The way it was written was that it would 
also report back the desired number of outputs were produced even if they were 
not. This worked fine for the audio_sink. I had no issues like to the audio 
through my sound card / sound server. However with the wav file recorder, it 
lead to the slowed down sounds and the actual playing time of the wav file 
being many times longer than it should have been.  

When I switched the number of outputted items return by general_work to be the 
actual number of samples the were processed and ready to be outputted, the wav 
file sink started to work. The audio quality of the recorded wav file is still 
a little worse than the sound from sound quality. I think the reason this works 
is because the audio sink is "clocked" by the sound card and it only requests 
more samples once the buffer for the sound card is empty. On the other hand, I 
don't think the wav file sink is really rate limited, it seems to request more 
samples from the vocoder at a much higher rate. When the block lies and just 
keeps giving it empty samples whenever the wav file sink asks, the play time 
gets inflated and the actual audio bits get watered down with these fake 
samples. However, the weird thing is that the audio from the sound card now 
sounds weird when the vocoder only gives out samples when there is actual data. 
I think, this is because when there is actual data coming in there should be 
some empty blocks in between to reconstitute things.

Is this just crazy talk or does it sound right?

Here is the wav file were it is using only the actual samples produced and it 
is intelligible:
https://soundcloud.com/hackrfsounds/only-recieved-frames

And here is the wav file where the vocoder block always returns the requested 
number of samples even if nothing was output:
https://soundcloud.com/hackrfsounds/moto-smartnet-recording

My GRC file and the DSD block is here:
https://github.com/robotastic/gr-dsd
If you change /lib/dsd_block_ff.cc on line 365 & 366 you can change how the 
number of outputted samples is determined.

I have the C++ program the uses this all here: 
https://github.com/robotastic/sdr  under the smartnet directory


 - Luke

On Aug 30, 2013, at 8:53 PM, Andrew Davis  wrote:

> I'm not sure about dsd but becouse of the ratio of symbol rate to sample 
> rate, some digital decoders will take a variable number of inputs per output, 
> this could without a sizable buffer under-run your sound card, some sound 
> servers handle these gaps in the sample stream for you. 
> 
> Also have you tried just playing the .wav's in a music player? I have had 
> issues with the wavfile_sink messing up the format. Also check that you are 
> feeding the wavfile_sink in the format, could you just post your .grc file 
> here?
> 
> Andrew
> 
> 
> On Fri, Aug 30, 2013 at 8:23 PM, Luke Berndt  wrote:
> Thanks Andrew! - I am actually able to play the sound fine through sound card 
> using the audio_sink block. It was is when I try recording it to a .wav file 
> using the wavfile_sink block that the sounds becomes distorted. I have tired 
> using a resampler and also tried a variety of different sample rate on the 
> wavfile_sink, but none of them sounded normal.
> 
> gr-dsd is a vocoder block and its decoding is sort of bursty. Sometimes it 
> seems to only take 4 input packets to equal 1 output, others it is 8 or 11. 
> Any wise, I am wondering I am getting some form of under run. I am not 
> getting 'aUaU' on the screen. Sometimes the sound from audio sink initially 
> sound garbled but then becomes normal, so I wonder if it is an issue of 
> needing to buffer up. I have tried adding in a Forecast, but it didn't help.
> 
> Any other tips would be great!
> 
>  - Luke
> 
> On Aug 30, 2013, at 5:03 PM, Andrew Davis  wrote:
> 
>> I'm not sure exactly what you are doing, but some sound cards don't support 
>> very many rates, windows always re-samples to some rate supported by the 
>> card, in linux you get more direct access to sound hardware and so you can 
>> send it rates it may not like, you could add a re-sampler/sound manager like 
>> pulse to handle all this for you, worked for me with similar issues.
>> 
>> Andrew
>> 
>> 
>> On Fri, Aug 30, 2013 at 10:53 AM, Luke Berndt  wrote:
>> So I clearly have a sample rate mis-match. I am trying to record the audio 
>> from the gr-dsd block. I don't seem to have an issue doing it using GRC. 
>> However when I try doing using C++ the audio sounds extra 

Re: [Discuss-gnuradio] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Luke Berndt]

Thanks Andrew! - I am actually able to play the sound fine through sound card 
using the audio_sink block. It was is when I try recording it to a .wav file 
using the wavfile_sink block that the sounds becomes distorted. I have tired 
using a resampler and also tried a variety of different sample rate on the 
wavfile_sink, but none of them sounded normal.

gr-dsd is a vocoder block and its decoding is sort of bursty. Sometimes it 
seems to only take 4 input packets to equal 1 output, others it is 8 or 11. Any 
wise, I am wondering I am getting some form of under run. I am not getting 
'aUaU' on the screen. Sometimes the sound from audio sink initially sound 
garbled but then becomes normal, so I wonder if it is an issue of needing to 
buffer up. I have tried adding in a Forecast, but it didn't help.

Any other tips would be great!

 - Luke

On Aug 30, 2013, at 5:03 PM, Andrew Davis  wrote:

> I'm not sure exactly what you are doing, but some sound cards don't support 
> very many rates, windows always re-samples to some rate supported by the 
> card, in linux you get more direct access to sound hardware and so you can 
> send it rates it may not like, you could add a re-sampler/sound manager like 
> pulse to handle all this for you, worked for me with similar issues.
> 
> Andrew
> 
> 
> On Fri, Aug 30, 2013 at 10:53 AM, Luke Berndt  wrote:
> So I clearly have a sample rate mis-match. I am trying to record the audio 
> from the gr-dsd block. I don't seem to have an issue doing it using GRC. 
> However when I try doing using C++ the audio sounds extra slow and choppy and 
> the playing time is much longer than I was actually recording for. I gr-dsd 
> block is supposed to output audio at 8khz. I have the wavfile_sink set at 
> 8000 for the samples per sec parameter. I use the same setting in GRC and it 
> works fine. I have also tried passing this through a resampler to get the 
> audio rate up to 44.1khz and I still have the same problem. If I use an 
> audio_sink set to a sample rate of 44100 instead, I am able to listen to the 
> audio with no problem.
> 
> Any idea what is going on or what I can try?
> 
> Here is a sample of the output: 
> https://soundcloud.com/hackrfsounds/moto-smartnet-recording
> 
> Thanks!
> 
> 
> ___
> 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] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Luke Berndt]

So I clearly have a sample rate mis-match. I am trying to record the audio from 
the gr-dsd block. I don't seem to have an issue doing it using GRC. However 
when I try doing using C++ the audio sounds extra slow and choppy and the 
playing time is much longer than I was actually recording for. I gr-dsd block 
is supposed to output audio at 8khz. I have the wavfile_sink set at 8000 for 
the samples per sec parameter. I use the same setting in GRC and it works fine. 
I have also tried passing this through a resampler to get the audio rate up to 
44.1khz and I still have the same problem. If I use an audio_sink set to a 
sample rate of 44100 instead, I am able to listen to the audio with no problem.

Any idea what is going on or what I can try?

Here is a sample of the output: 
https://soundcloud.com/hackrfsounds/moto-smartnet-recording

Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing multiple signals off single source block

[Luke Berndt]

> Xlating FIRs just generate the sin internally and apply it themselves; they 
> are mathematically equivalent to shifting your signal and filtering it 
> afterwards.
> You can, of course, use bandpasses, if you're after a specific sprectral 
> shape. Try the gr_filter_design toolbox, it's even neater than doing your 
> calculations in Matlab (or scipy).
> However, as Mike already pointed out, depending on your signal and potential 
> interferers of course, selection by trunkated fft is faster and as intuitive.

Awesome - I will stick with Xlating FIRs then. I will have to get smarter on 
how to use the FFT to do the frequency shifting. I checked out Mike's app, but 
I don't have 3.7 installed yet so I couldn't play around with it.
 
> I'm not quite sure I understand your question correctly. GNU Radio has 
> built-in concurrency for blocks. 
> Tom Rondeau has a blog entry on core affinity, 
> seehttp://gnuradio.squarespace.com/home/2013/2/7/block-core-affinity.html .

I will give the block core affinity a try. I think what maybe happening is that 
2 process heavy blocks are being scheduled for the same core. I have a 4 core 
machine and it is only hitting ~60% CPU utilization, but it stops/slows 
decoding the trunking stream while it is doing vocoder work. It doesn't seem to 
have a problem doing NBFM Demod and recording, so I think the additional 
processing requirements of decoding digital audio is the problem. The 
Performance Counters seem like a great approach. It should give me a better 
idea where all the cycles are going. The network source/sink approach also 
sounds like a good one. And I have a spare laptop... :)


> Awesome project!

Thanks! I am having way too much fun with a $20 dongle. GNURadio is awesome. ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio